IBM Books

MRS V3.4 Protocol Reference V2


Using DNA IV

This chapter describes IBM's implementation of Digital Network Architecture Phase IV (DNA IV) and includes the following sections:


DNA IV Overview

DNA IV is a collection of software components that transfer information between networks connected by physical media. By transferring information, DNA IV software facilitates communication between network devices, such as personal computers, file servers, and printers.

DNA IV protocol is the underlying protocol for Digital Equipment Corporation's DECnet software products as well as DNA-compatible products. DNA IV protocol includes the following:

DNA IV performs two major functions:

DNA IV supports the following:

Special consideration should be given to the following DNA IV restrictions:

DNA IV Terminology and Concepts

This section contains a brief description of DNA IV terminology.

Addressing

Each node has a 16-bit node address, which is the same for all interfaces on that node. An address consists of 2 fields: 6 bits of area number and 10 bits of node number. Addresses are printed in decimal with a period separating the area and the node, such as 1.7 is node 7 in area 1. If no area is given, area 1 is assumed. Any address in the range 1.1 to 63.1023 is legal. Both nodes and areas should be numbered starting from 1, with few, if any, gaps. This is because the maximum node number and the maximum area numbers are configuration options and control the size of many of the routing data structures.

There is no direct correlation between addresses and physical cabling. Routes are computed to nodes, not wires.

Ethernet Data Link Addressing

Each Ethernet interface is set to the same 48-bit physical address, which is the concatenation of a 32-bit prefix (AA-00-04-00) and the 16-bit DNA IV node address. The node address is byte-swapped (to convert from PDP11 to Ethernet byte order). Thus, DNA IV node 1.1 has Ethernet Address AA-00-04-00-01-04.

Multicast (not broadcast) is also used in routing. The three multicast addresses used by DNA IV are AB-00-00-02-00-00, AB-00-00-03-00-00, and AB-00-00-04-00-00.

802.5 Token-Ring Data Link Addressing

The implementation of DNA over IEEE 802.5 Token Ring conforms to the DECnet Digital Networking Architecture (Phase IV) Token-Ring Data Link and Node Product Functional Specification, Version 1.0.0, that includes support for Arbitrary MAC Addresses (AMA).

There are two types of MAC addressing, conventional DNA IV addressing, which is the concatenation of a 32-bit prefix (AA-00-04-00) and the 16-bit DNA IV area/node address or AMA that allows the DNA protocol to run on IEEE 802.5 nodes without their MAC addresses being changed by the DNA protocol. This is necessary if you follow certain IBM protocol conventions. You can select the type of addressing that you are using through the DNA configuration process (NCP>).

Another type of addressing representation is native bit-order. This type of address is byte-flopped when sent over the physical layer. For example, the canonical 32-bit prefix shown above (using dashes) is expressed as 55:00:20:00 in native bit-order with colons separating each byte.

Note:When configuring DNA IV to run over ATM LAN Emulation, the AMA must be used.

X.25 Data Link Addressing

The router supports DECnet Phase IV over X.25 and can interoperate with routers running Digital's implementation of DECnet Phase IV over X.25.

You set up the local and the remote DTE address with the set/define circuit command when you set up a DECnet circuit. In the call-userdata parameter you specify the local DTE address in hexadecimal octets (characters). In the DTE-address parameter you specify the remote address in hexadecimal octets. Both the local and remote DTE addresses can be up to 14 hexadecimal octets in length with two ASCII characters representing one hexadecimal octet.

Routing

DNA IV handles both forwarding of DNA IV data packets and automatic routing with other DNA IV nodes. The router performs the following DNA IV functions:

All end and routing nodes periodically broadcast hello messages to the all-routers multicast address. This allows each router to locate other nodes in its area.

On each broadcast network (for example, Ethernet, Token-Ring), one router declares itself the designated router for that wire. The designated router broadcasts its presence so that the end-nodes know to use it as their default gateway. Any end-node sending a packet to a node not on that wire automatically sends it to the designated router for forwarding.

In a multi-area DNA, assign priorities to routers in such a way that the designated router is a level 2 router, or is likely to be the best next hop to commonly-used destinations. This reduces the possibility of traffic from end-nodes having to take an extra hop.

Routing decisions are based on a least-cost algorithm. Each link (e.g., point-to-point, broadcast network, hop) has a cost. Every router broadcasts (to other routers only) its cost and the number of hops to get to every node in its area. In this way, each router finds the cheapest path, subject to a maximum hop count.

Routing Tables

A router forwards any DNA IV data packet it receives to the proper node based on its routing table. To maintain its routing table, a router listens to and sends level 1 updates to every node in its area. If the router's type is set to AREA, it also exchanges level 2 routing updates.

Each router maintains a routing table with an entry for every node (up to the maximum address) and every possible next hop (all circuits and up to the maximum broadcast routers). Each entry in this table contains the cost and hop to reach a node via one circuit or next hop node. Once a second the routing table sends out a broadcast routing timer.

Area Routers

If the router is configured as an area router, it maintains a similar database for all of the areas up to the maximum area, and can exchange area routing information with other area routers. Areas are handled almost exactly the same as nodes, except messages give costs to areas, but not nodes.

The areas concept results in two types of routing nodes:

End-nodes simply pass packets on to a router.

A level 2 router that can reach other areas advertises a route to node 0 within its area. When level 1 routers need to send a packet to another area, they route it toward the closest node 0. This is not necessarily the best route to that area. From there, the level 2 routing algorithm sends the packet to its destination area.

Configuring Routing Parameters

In each system you can set the following routing parameters:


IBM's Implementation of DNA IV

The main user interface program for the router's implementation of DNA IV is called NCP. The router's NCP is a limited subset of the DECnet Network Control Program (NCP) commands. The router's NCP enables you to view and modify the various operating arguments of DNA IV and to read various DNA-specific counters.

Some of the features of the router's NCP include the following:

The router NCP is similar to NCP on DECnet-VAX, with the following differences:

Important

Before configuring DNA IV, you need to be aware of the optional security features discussed in:

If you already are familiar with these topics, skip these two sections and begin reading at "Configuring DNA IV".

Managing Traffic Using Access Control

Access control protects one group of nodes from other nodes on the network. Routers make all nodes on a network accessible to each other. Usually, the main forms of security are passwords and conservative use of DNA IV proxy access at the host level.

However, due to differences in the security level of machines, you might need to provide additional security by limiting access within the routers in the network. The DNA forwarder enables you to do this using access controls.

Generally, access controls are not recommended due to the following liabilities:

Access control prevents the forwarding of DNA IV (Long Format) data packets on the basis of source address, destination address, and interface. Access control does not affect routing packets, because they use a different packet format. This makes configuring access control safer, because you cannot break the routing protocol.

To implement access control, addresses are masked and compared. That is, the address in question is masked with 1s in the bit positions to be tested, and 0s in the free area. The address is then compared to a fixed value. For example, you could use a mask of 63.1023 (all 1s), and compare it to a result of 6.23 which would be true only for node 6.23. You could use a mask of 63.0 and a result of 9.0 which would be true for any node in area 9.

These mask and compare values come in pairs for source and destination address. They are then formed into lists for an interface. Each interface can have one access control list, which is applied to packets received on that interface. This list may be inclusive or exclusive. An inclusive list is a set of address pairs that designates a corridor for traffic flow. An exclusive list is a set of address pairs that does not allow traffic flow.

In an inclusive list, the source and destination addresses are tested using the mask and compare values. If any entry's source and destination matches, the packet is forwarded. In an exclusive list, the source and destination addresses are tested using the mask and compare values. If any entry's source and destination matches, the packet is dropped. The choice between exclusive and inclusive should be made on the basis of which list will be shorter. However, exclusive access control is usually easier to configure.

When packets are dropped due to access controls, the Return to Sender Request (RQR) bit is set in the Long Format Data Packet header and the packet is returned. Then, the connect request immediately fails, because NSP Connect Initiate packets are normally sent with the RQR bit set.

Configuring Access Control

Access control limits access to a particular host or group of hosts. You must assign access control to all routes to that host, not just the preferred route. Otherwise, access control functions when the primary route is up, but fails when the secondary route is in use.

On your network map, draw a line to isolate the secure region from the rest of the network. Ideally the line should cross the minimum possible set of adjacencies so that the least number of interfaces are running with access control. For broadcast networks (Ethernet and Token-Ring), draw the line through the drop cable to the node, to identify the interface to filter. For each interface crossed by the access control line, use NCP to define the same access control list.
Note:Because all DECnet applications use the NSP protocol, which requires bidirectional connectivity, you do not need to define access controls in both directions.

Inclusive Access Control

In Figure 15, node 1.13 wants to communicate with nodes 1.2 and 1.4 only. Access control allows you to secure nodes from all nodes connected by routers. Therefore, in Figure 15 you can protect node 1.13 from all nodes except node 1.9 because these two nodes share the same physical network. To configure the desired access control for this example, build an inclusive filter on interface Eth/0 of router 1.19 as shown in the bottom of Figure 15

Figure 15. Example of Inclusive Access Control


example of inclusive access control

The first and second entries of the inclusive filter information shown in Figure 15 allow nodes 1.2 and 1.4 to send packets to node 1.13. The third entry allows any node to send to node 1.9 (you are not trying to secure node 1.9).

To configure the example given for router 1.19, enter the following NCP commands and parameters:

  NCP> def mod access-cont circ eth/0 type inclusive
  NCP> def mod access-cont circ eth/0 filter 1.2 63.1023 1.13 63.1023
  NCP> def mod access-cont circ eth/0 filter 1.4 63.1023 1.13 63.1023
  NCP> def mod access-cont circ eth/0 filter 0.0 0.0 1.9 63.1023
  NCP> def mod access-cont circ eth/0 state on

Exclusive Access Control

Figure 16 shows how exclusive access control isolates node 4.4 from the rest of the campus.

Figure 16. Example of Exclusive Access Control


Example of Exclusive Access Control

Configure the desired access control for this example by building an exclusive filter on the PPP/0 interface of router 4.3 as shown in Figure 16. To configure the example given for router 4.3 in Figure 16, enter the following NCP commands and parameters:

  NCP> def mod access-cont circ ppp/0 type exclusive
  NCP> def mod access-cont circ ppp/0 filter 0.0 0.0 4.4 63.1023
  NCP> def mod access-cont circ ppp/0 state on

Managing Traffic Using Area Routing Filters

Area routing filters allow special configurations of your DNA network. Because this is an advanced topic, very few DNA IV networks need routing filters. There are two primary applications for area filtering in DNA IV:

Area routing filters allow you to configure a router to control the information about DECnet areas that are sent or accepted in level 2 routing messages. You may configure separate incoming and outgoing filters for each interface. Each filter specifies which areas routing information will be passed to or accepted from.

When a network sends a level 2 routing update and there is a routing filter, the entry (RTGINFO) for any area not in the filter has the cost of 1023 and a hop count of 63. Any area in the filter has the correct cost and hops placed in the entry.

When the network receives a level 2 routing message and there is a routing filter, any entry for an area not in the filter is treated as if the cost is 1023 and the hop count is 63 (unreachable). Any routing entry from the packet that is in the filter is processed normally.

The routing filters affect the processing of level 2 routing messages only. There are no filters for level 1 routing messages. Routing filters have no effect on router hello processing, and do not prevent area routers from developing adjacencies. They affect the area routing database. If the filters prevent an area router from learning about another area, they would prevent the router from becoming attached, and then the router could not advertise as an area router.

Security by Area Filtering

Like access controls, routing filters provide security. However, routing filters have some disadvantages compared to access controls:

However, area filtering is more efficient because there is no need to check every packet. In the following example area filtering occurs in an area that contains workstations that are part of a large network that contains machines with confidential information. There might be one machine outside the area that the confidential machines need to reach for information.

In Figure 17, area 13 contains workstations that need to be able to reach area 7. Node 13.1 is the router, and the other nodes are the workstations. Node 13.1 has a filter to accept only routes to area 7. Therefore, if node 13.1 receives a packet from any node in area 13 not destined for area 7, node 13.1 cannot forward the packet and sends the sending node an error message.

To configure router 13.1 in Figure 17, enter the following NCP commands and parameters:

  NCP> def mod routing-filter circ eth/1 incoming area 7
  NCP> def mod routing-filter circ eth/1 incoming state on

Figure 17. Example of Area Routing Filter for Security


Example of Area Routing Filter for Security

Blending DECnet Domains

DECnet has a 16-bit node address space with a fixed hierarchy of 6 bits of area and 10 bits of node. By comparison, IP has a 32-bit node address space with a flexible multilevel hierarchy. Many established networks have now grown to the point where they use all 63 areas. The problem is that as different facilities connect to each other, they want to connect their DECnet networks but cannot due to area number conflicts.

The only solution is to redesign the DECnet architecture. (This is addressed by DECnet Phase V.) However, by using area routing filters, it is possible to allow some overlap between two DECnet domains.

Domain is not a standard DECnet term; it is used here as a name for a DECnet wide-area network, presumably one with many areas. The goal is to blend two of these domains, so that there is a common area that can reach parts of both domains. However, there are more than 63 areas in the union of the two domains. Because area filtering is not simple to administer and is restrictive, you should not consider using it if there are enough area numbers available for the union of the domains.

To configure the overlap of two domains, first you must decide which areas to intersect. These areas are the ones that will be able to participate in both domains. These area numbers must not be used elsewhere in the two domains.

Figure 18 shows the areas that intersect are areas 1 and 2. The remainder of the areas can be duplicated between the two domains. In the example, there are two areas 3, 4, and 5, one in each domain. Note that it is never possible to allow direct connection between a node in area 3 in domain A and area 3 in domain B. The best that you can do is give the areas in the intersection the ability to talk to portions of each domain.

In designing the intersection, be careful that neither domain relies on routes through the intersection to maintain connectivity between areas that are not in the intersection. Because the routes in and out of the intersection are filtered, they probably do not offer normal reachability between all areas in the domain.

To decide how to configure the routing filters, draw a concise map of the configuration. On this map, locate all of the areas and outline the two domains. Then decide upon the filtering fence that you need to establish. Carefully go around the intersection of the two domains and locate all level 2 adjacencies that cross the filtering fence. These are one hop communications paths between level 2 routers that cross between areas.

In the example, there are six adjacencies that cross the fence, 1.18 to 5.7, 1.18 to 5.8, 1.18 to 8.3, 2.17 to 3.12, 2.21 to 4.7, and 2.21 to 4.9.

The first step in designing the area filters is to set up filters that keep the areas in one domain from being propagated into the other domain. The only area routes that should leave the intersection are those for areas in the intersection. In the example, these are areas 1 and 2. Therefore, only routes for areas 1 and 2 should be sent from nodes such as 2.17 and 3.12.

On point-to-point links such as 2.17 and 3.12, it does not matter which end filters, but it is probably safer to filter on the sending end. Therefore there would be a filter on the interface of 2.17, allowing forwarding only routes from areas 1 and 2. The same would occur on the two interfaces of 2.21 and the link from 1.18 and 8.3.

When the hop between two areas is an Ethernet or other broadcast media, such as 1.18 to 5.7 and 5.8, you should make the decision on another basis. Most Ethernets have most of the level 2 routing nodes in one area, and a few in the second area. Here, the filtering should be on the few, rather than the many. In the example, node 1.18 is the interloper on the Ethernet in area 5, so it should filter. Mode 1.18 would send routers only for areas 1 and 2 on the Ethernet.

You can filter on both ends of an adjacency. This adds an extra layer of security against accidental reconfiguration. However, if you set up only one end for filtering, then only that end filters.

Given these filters, the two domains cannot contaminate each other. However, for a node in the intersection, it is not clear which area 3 will be reached when a connection is attempted to node 3.4. It depends on the current route and the circuit costs. Clearly, this is not ideal. It does not matter that there might only be a node 3.4 in domain A and not in domain B. Routing between areas is done solely on the basis of area; only the routers inside an area know the routes to nodes in that area.

Thus, you must establish a second set of filters to decide which instance of an area (domain A or B) is reachable from the intersection for each area not in the intersection. Therefore, you could decide that nodes in the intersection could reach areas 3 and 4 in domain A and area 5 in domain B. In the example, this would be done by configuring routers 1.18 and 2.21 to only accept routes to areas 3, 4, 6, and 8 from domain A. Routers 2.17 and 2.21 would only accept routes for areas 5 and 9 from domain B.

Therefore, nodes in the intersection see a universe that contains areas 1 and 2 from the intersection, areas 3, 4, 6, and 8 from domain A, and areas 5 and 9 from domain B.

To configure router 1.18 in Figure 18, enter the following NCP commands and parameters:

  NCP> def mod routing-filter circ eth/0 outgoing area 1,2
  NCP> def mod routing-filter circ eth/0 outgoing state on
  NCP> def mod routing-filter circ eth/0 incoming area 3,4,6,8
  NCP> def mod routing-filter circ eth/0 incoming state on
  NCP> def mod routing-filter circ ppp/0 outgoing area 1,2
  NCP> def mod routing-filter circ ppp/0 outgoing state on
  NCP> def mod routing-filter circ ppp/0 incoming area 3,4,6,8
  NCP> def mod routing-filter circ ppp/0 incoming state on

Figure 18. Example of Blending DECnet Domains


Example of Blending DECnet Domains

There is still no way that a node in domain A area 5 can communicate directly to a node in domain B area 5. For nodes in these two areas to communicate, you must do a series of application-level relays using the set host command. For example:

Configuring DNA IV

The DNA IV protocol runs over Token-Ring, Frame Relay, Ethernet, PPP, Token-Ring ATM LAN Emulation clients, Ethernet LAN Emulation clients,and X.25 interfaces. The following sections describe the procedures for configuring the DNA IV protocol to work over Token-Ring and X.25 interfaces.
Note:When operating in mixed DNA IV and DNA V networks, all DNA IV configuring and monitoring must be done from the process described in this chapter.

DNA IV and DNA V Algorithm Considerations

DNA IV uses a distance-vector routing algorithm. DNA V can use either a distance-vector or a link-state routing algorithm. The algorithm that the bridging router selects is according to what protocol is enabled and disabled, and any combinations that can result from these two protocols. See Table 104 for details.

Table 104. DNA IV and DNA V Algorithm Considerations
DECnet IV Status OSI/DNA V Status Algorithm Selected
Enabled Disabled Distance-vector (automatically)
Disabled Enabled Link-state (automatically)
Enabled Enabled Use the set algorithm command to configure this information into SRAM.

Configuring DNA IV For Token Ring

The procedure to run the DNA IV protocol over 802.5 Token Ring (TR) involves commands from the DNA IV and Token-Ring configuration processes.

  1. From the OPCON prompt (*) enter the configuration process.
    * talk 6
    Config>
    
  2. Enter list device to see the interface numbers for the Token-Ring interfaces. Note the interface number of each Token-Ring interface.
    Config> list device
    
  3. Use the network command with the interface number of the Token-Ring interface you want to configure. This places you in the Token-Ring configuration process.
    Config> network 0
    TKR config>
    
  4. Use the list command to verify the Token Ring configuration information.
    TKR config> list
     
    Token-Ring configuration:
     
    Packet size (INFO field):    2052
    Speed:                       4 Mb/sec
    Media:                       Shielded
     
    RIF Aging Timer:             120
    Source Routing:              Enabled
    Mac Address    000000000000
    
  5. Exit the Token-Ring configuration process and enter the DNA NCP configuration process.
    TKR config> exit
    Config> protocol DN
    NCP>
    
  6. Use the define command to define a DNA circuit on the Token-Ring interface:
    NCP> define circuit tkr/0 state on
    
  7. Optionally use the define command to set the routing type for the circuit. For bilingual or Phase IV support, you need to change the routing type from the default (standard) to either bilingual or AMA.
    NCP> define circuit tkr/0 router type bilingual
     
                       or-
     
    NCP> define circuit tkr/0 router type AMA
    
  8. Use the list command to check the parameters.
    NCP> list circuit tkr/0 characteristics
    Circuit Permanent Characteristics
    Circuit             = TKR/0
    State               = On
    Cost                = 4
    Router priority     = 64
    Hello timer         = 15
    Max routers         = 16
    Router type         = Standard
    
  9. Restart the router, so that all configured parameters take effect.
Note:If you want to disable source-routing or set the RIF-timer to a value other than the default value, use the source-routing command and the set RIF-timer command in the Token-Ring configuration process.

Configuring DNA IV for X.25

The procedure to run the DNA IV protocol over X.25 circuits involves commands from the X.25 and DNA IV configuration processes.

  1. From the OPCON prompt (*) enter the configuration process. Go to "t 6" and enter X.25 config (net #). If this is the first time X.25 is being configured then do the following:
    1. DEFINE the router's DTE address.
      X.25 Config> set address
      
    2. DEFINE each protocol that will be supported over X.25:
      X.25 Config> add protocol
      

      IP
      It is usually a good idea to add this protocol so that you can verify the general X.25 configure is OK

      DN

      Note: Allow protocol parameters to default.

    3. DEFINE protocol remote address to the remote X.25 address mapping for the protocols that require this:
      X.25 Config> add address
      

      for IP:

      • IP address = 128.185.247.22
      • X.25 address = 22

      for DN:

      • DN address = 5.22
      • X.25 address = 22
    4. VERIFY that one end of the X.25 circuit is a DTE and the other end is a DCE.
      X.25 Config> list all
      

      Check the National Personality field for device type. For a national personality type of GTE-Telenet you see:

         National Personality: GTE Telenet (DTE)
       
                         -or-
       
         National Personality: GTE Telenet (DCE)  
      

      To change the device type to DCE, enter:

         X.25 Config> set equipment-type dce
      

      Lists all parameters configured for X.25

      National Personality: GTE Telenet (DTE) National Personality: GTE Telenet (DCE)

      If not, then chose one router to act as a DCE and modify as such,

      X.25 Config> set national-personality dce
      
    5. RESTART the router, so that all configured parameters take effect.
    6. To VERIFY that the configuration is valid after a restart, go to the monitor side and observe if the link is coming up.
      * t 5
      + c
      

      This gives you the state of the link at that time. If you see the state of the X.25 link transitions from "testing" to "down", go to ELS messages and see if there is an obvious error. If the state of the X.25 link transitions from "testing" to "up", then chances are the x.25 configuration is valid.

  2. To VERIFY that the X.25 link is operational:
    1. TRY to PING each end of the X.25 link from the IP monitor:
      IP> interface
      

      Verify that the correct X.25 addresses had been configured in the IP protocol.

      IP> ping IP address of remote X.25 link
      
  3. To CONFIGURE DECnet PhaseIV on the Router:
    1. DEFINE DECnet Executor parameters:

      NCP> define exec address area.node
      Router's DECnet address

      NCP> define exec type DEC-ROUTING-IV
      Configures the router as a LEVEL 1 DEC type router
      Note:This example is for configuring a router to interoperate with other routers supporting the DEC-routing standard over X.25 networks. A router supporting the standard must be defined as type DEC-ROUTING-IV (level 1) or DEC-AREA (level 2). The default routing type is ROUTING-IV and AREA which allows interoperation with many existing IBM 2210 and other compatible routers.

      NCP> define exec state on

      Restart the router so that when you configure the X.25 circuit, all DEC specific parameters are visible. To verify executor configuration, NCP> show executor characteristics

    2. DEFINE PhaseIV X.25 circuits.

      You must configure the X.25 circuit as either a PVC or SVC. If this circuit is configured as a PVC then the other end must also be a PVC. If this circuit is configured as an IN-SVC, then the other end must be configured as an OUT-SVC

      NCP> define cir x25/0 usage IN-SVC
      NCP> define cir x25/0 DTE-address "remote X.25 DTE"
      NCP> define cir x25/0 call-data
      NCP> define cir x25/0 verification enabled
      

      Enabling verification is optional.

    3. DEFINE circuits to the active state:
      • for Token-Ring

        NCP> define cir TKR/0 router type bilingual

      • for ALL circuits

        NCP> define cir xxx state on

      Restart the router so that all of the DECnet parameters become effective, VERIFY the X.25 configuration within the DECnet protocol is as you want it.

      NCP> list circuit x25/0 characteristics
      


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]